In a conventional Public Switched Telephone Network (PSTN), great attention is paid to QoS all the time; a conventional transport service is relatively undiversified, and an operation region of the network is also relatively undiversified, therefore, it is only necessary to ensure the QoS of a transport layer. A code flow transported in a Next Generation Network (NGN) may be low-speed and long-delay non-real-time data, or may be a high-speed and low-delay multimedia flow, or coexistence of these real-time and non-real-time data flows. The data flows of different media have stricter requirements on peer-to-peer QoS in the NGN.
An IMS, as an important evolution of the NGN, provides guarantee for the QoS of the network. FIG. 1 is a reference frame of QoS control in an IMS, wherein an Rx interface is a standard interface between a P-CSCF and a Policy and Charging Rule Function (PCRF). The whole framework includes User Equipment (UE) 101, a P-CSCF 102, a PCRF 103 and a Serving Call Session Control Function (S-CSCF) 104, and in addition, functional entities such as an Interconnection Border Control Function (IBCF) 105, an Interrogating Call Session Control Function (I-CSCF) 106 and a Media Gateway Control Function (MGCF) 107 are also involved in a session process.
According to a description of 3rd-Generation Partnership Project (3GPP) standard protocol TS29.214, Policy and Charging Control (PCC) is implemented by virtue of an Rx reference point in the IMS. According to the description of the protocol, an Application Function (AF) provides session information for a PCRF network element, the session information is partially mapped from a Session Description Protocol (SDP) in SIP signalling into a related flow information Attribute Value Pair (AVP) in a Diameter Authorization Authentication Request (AAR) message according to the description of 3GPP TS29.213, and corresponding information is media flow information controlled by the PCRF. The AF corresponds to the P-CSCF in the IMS, the AVP refers to an attribute value pair specified in a Diameter protocol.
SIP Forking is a basic function of the IMS. SIP Forking refers to that multiple terminals share the same user number, and may use different bearers or have different capabilities; when the user number is a called user number, an IMS network searches for called user terminals in a parallel or serial selection manner, and a calling user selects one called user terminal for communication according to a certain strategy. In regardless of serial or parallel selection manner, a P-CSCF on a calling side needs to provide a PCRF with a media resource negotiated by the calling user and the selected called user terminal.
In a current protocol, under an SIP Forking scenario, a flow of a QoS bearer resource control function on a calling side is shown in FIG. 2, and for example, if there are two paths, the flow includes the following steps that:
Step 201: a UE initiates a call, wherein an INVITE request message includes an SDP offer;
Step 202: when a P-CSCF receives the call, the P-CSCF maps the SDP offer into downlink media information;
Step 203: the P-CSCF forwards the INVITE request message to an S-CSCF, and the S-CSCF transmits the INVITE request to called UE;
Step 204-Step 211: a processing flow is implemented after the calling P-CSCF receives INVITE 180 requests from two terminals.
Here, for the calling P-CSCF, there are two paths of SIP sessions, wherein one path is an SIP session between a calling UE and UE1, and the other path is an SIP session between the calling UE and UE2. In Step 205, a Diameter session created between the P-CSCF and the PCRF is configured to transmit the Diameter AAR message corresponding to the first path in Step 205 and the Diameter AAR message corresponding to the second path in Step 209; an SIP-Forking-Indication AVP in the Diameter AAR message in Step 205 is SINGLE_DIALOGUE(0), and simultaneously contains media information negotiated by UE1; when receiving an INVITE 180 request from the second path, the P-CSCF can determine that Forking occurs at the called UEs, wherein the SIP-Forking-Indication AVP in the Diameter AAR message is SEVERAL_DIALOGUES(1), and simultaneously contains media information negotiated by UE2;
Step 212: the S-CSCF forwards to the P-CSCF an INVITE 200 OK response returned by the terminal on the first path, wherein the INVITE 200 OK response includes an SDP answer;
Step 213: when the P-CSCF receives the INVITE 200 OK response, the P-CSCF maps the SDP answer into uplink media information;
Step 214: the P-CSCF transmits the Diameter AAR message corresponding to the media negotiation between the calling UE and the called UE1 to the PCRF network element to request for resource authorization, wherein a Media-Component-Number AVP and a Flow-Number AVP are written into the Diameter AAR message to identify an IP Flow generated by combination of uplink and downlink media information, and the SIP-Forking-Indication AVP is written as SINGLE_DIALOGUE(0); wherein the IP Flow is a media resource negotiated by the calling UE and the selected called terminal;
Step 215: when the PCRF receives the SIP-Forking-Indication AVP which is SINGLE_DIALOGUE(0), or when the PCRF receives an AVP with no SIP-Forking-Indication AVP, a PCC rule is updated according to the media resource contained in the current Diameter AAR message, and meanwhile, a PCC rule unmatched with the IP Flow contained in the current Diameter AAR message is removed, that is, the PCC rule corresponding to the IP Flow negotiated by the calling UE and the called UE2 is removed, and a Diameter Authentication, Authorization and Accounting (AAA) response is transmitted to the P-CSCF;
Step 216: the P-CSCF forwards a session response to the calling UE;
Step 217: if a calling user selects to answer the terminal from the first path, the calling user needs to transmit a BYE request to remove the SIP session which has been established by the calling UE and UE2;
Step 218: the P-CSCF releases a session resource established by the calling UE and UE2;
Step 219: the P-CSCF transmits a Diameter Session Termination Request (STR) to the PCRF, and the PCRF may release a bearer resource which has been applied for; and
Step 220: the P-CSCF forwards the BYE request.
It can be seen from the above flow that, in an SIP Forking scenario in the prior art, when the P-CSCF receives the first INVITE 200 OK, the SIP-Forking-Indication AVP in the Diameter AAR message is set as SINGLE_DIALOGUE(0), the PCRF confirms the bearer resource which was finally applied for according to the corresponding IP Flow in the Diameter AAA request corresponding to the INVITE 200 OK, and then deletes the PCC rule corresponding to the IP Flow negotiated by the calling UE and the called UE2, the P-CSCF receives the BYE request of removing the session with UE2, and transmits the Diameter STR message, wherein the Diameter STR message will release all the bearer resources which were applied for this call.
However, under the SIP Forking scenario, according to the protocol description of the supported RFC3261, the INVITE 200 OK messages from multiple called terminals are transparently transmitted to the calling user in media resource access negotiation regardless of in a serial or parallel manner, the calling user finally selects a proper called terminal to answer according to its own preference condition and a support request from equipment, the calling user has the right to select, the selected answering terminal is not always the terminal which is the first one returning the INVITE 200 OK, but in the prior art, the answering terminal selected by the calling user is always the terminal which is the first one returning the INVITE 200 OK; in addition, under the SIP Forking scenario, in a media resource releasing process, as long as one called terminal has returned a temporary response (for example, an INVITE message 183), while the answering object finally selected by the calling user is not this called terminal, it is necessary to transmit a BYE message to release the SIP session established with this called terminal, however, in the prior art, the calling P-CSCF would inform the PCRF to release all the bearer resources.
Thus it can be seen that the problems of the prior art are as follows: 1) the media resource negotiation under the condition that multiple called terminals return INVITE 200 OK is not supported in a media resource access negotiation process under the SIP Forking scenario; and 2) if the calling UE transmits a BYE message to release one path of SIP session in the media resource releasing process under the SIP Forking scenario, all the bearer resources which have been applied for the whole call will be released, and the normal bearer resources of the call on any path cannot be ensured, so that the normal communication of a basic call cannot be implemented.
In a word, QoS bearer resource control in the media resource access negotiation process and the media resource releasing process under the SIP Forking scenario cannot achieve normal call processing under the SIP Forking scenario.